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REMARKS / ARGUMENTS 

Claims 1-15, 19 and 21-25 remain in the present 
application, of which claims 1, 7, 13 and 21 are independent. 
None of the claims has been amended herein. Applicants 
respectfully request reconsideration and allowance of claims 1- 
15, 19 and 21-25. 

Applicants appreciate the time and courtesy extended by the 
Examiner to applicants' attorney during the telephone interview 
of June 4, 2004. During the interview, applicants' attorney 
explained to the Examiner that the content of the amendment 
mailed January 20, 2004 (indicated on the Office Action as filed 
on January 22, 2004) was based on applicants' understanding of 
the telephone interview of January 16, 2004, the amendments to 
the proposed claims required by the Examiner during the 
telephone interview, and the Interview Summary and attachment 
faxed by the Examiner on January 16, 2004. Further, the Office 
Action was discussed in reference to U.S. Patent No. 5,515,077 
("Tateyama") and U.S. Patent No. 6,353,460 ("Sokawa et al . " ) . 
No agreement was reached except that applicants 1 attorney agreed 
to submit the arguments presented during the telephone interview 
in writing. 

Claims 1-15, 19 and 21-25 have been rejected under 35 
U.S.C. § 103(a) as allegedly being unpatentable over Tateyama in 
view of Sokawa et al . Applicants respectfully traverse because 
of at least the following reasons. 

In rejecting claim 1, the Office Action states "Tateyama 
teaches the method of horizontally scrolling a display window to 
the left comprising the steps of receiving a data packet (Y0 Yl 
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UO V0) (figure 28) that includes a field for a blank start pixel 
value (YO U0 V0) , which indicates a number of pixels to be 
blanked out." Applicants do not agree with this statement as 
follows. The detailed arguments below were not previously- 
presented in the amendment mailed January 20, 2004 because 
applicants believed that an agreement has been reached, and 
further arguments were not necessary. 

Tateyama describes FIG. 28 as "a table showing color 
vectors to be read and displayed in each scroll mode according 
to the invention." (Col. 3, lines 26-27). Tateyama further 
recites that "FIG. 28 shows color vectors to be read and 
displayed in each scroll mode. In this table, "m, " INVALID," 
DELAY TIMING, " + " and " - " represent (n-l)/2, no-display 
(transparent), delay time of the first vector factor from the 
read-timing, reading earlier and later, respectively." (Col. 9, 
lines 27-31) . Applicants do not see any other description of 
FIG. 28 in Tateyama. 

Claim 1 has been amended in the January 20, 2004 amendment 
for clarification to recite, in a relevant portion, "receiving a 
header data packet that includes a field for a blank start pixel 
value, which is a numerical value that indicates a number of 
pixels to be blanked out . " ( Emphasis Added ) 

First, applicants do not believe (Y0 Yl U0 V0) can be 
considered a header data packet, as FIG. 2 8 is merely a table, 
and there is no teaching or suggestion as to whether any 
numerical value that indicates a number of pixels to be blanked 
out is stored in a field of a header data packet as a blank 
start pixel value. 
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Second, even if (Y0 Yl YO V0) were to be considered a 
header data packet, it does not by itself include a field for a 
blank start pixel vale, which is a numerical value that 
indicates a number of pixels to be blanked out. By way of 
example, if Y0, Yl, UO and V0 are 55, 66, 77 and 88, 
respectively, applicants do not see how anyone can determine the 
number of pixels to blank out from a packet of (55, 66, 77, 88). 
Therefore, applicants submit that a data packet (Y0 Yl Y0 V0) 
does not include a field for a blank start pixel vale, which is 
a numerical value that indicates a number of pixels to be 
blanked out. 

Third, even if a packet is formed to include both (YO Yl U0 
V0) and (Y0 U0 V0) in a single packet, there is no way to tell 
how many pixels are to be blanked out if numerical values are 
used to replace (Y0 Yl UO V0) and (Y0 U0 V0) . By way of 
example, if (Y0 Yl U0 V0) and (Y0 U0 V0) are replaced by 
numerical values, and a packet consists of (55, 55, 77, 88) 1 and 
(55, 77, 88), there is no way to tell whether 55 in (55, 77, 88) 
represents Y0 or Yl without further information. On the other 
hand, if a packet containing (Y0 Yl U0 V0) and (Y0 U0 V0) is 
sent, since n Y0" , "Yl", "U0" and "VO" are not numerical values, 
they do not constitute a numerical value that indicates a number 
of pixels to be blanked out. 

The Office Action further states "Sokawa teaches a header 
data packet comprising the RGB signal data (col. 16, line 51), 
the image data unit of one pixel is 16 bits (col. 22, line 14), 
the head of the image data unit VS j , and the tail of the image 

1 In other words, the numerical value for Y0 is identical to the numerical value for Yl in this case. They are both 
55. 
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data unit of the former half Vsi (fig. 22, col. 28, lines 25- 
27)." Sokawa et al . recites: "[f]or example, the RGB signal 
output from the NTSC decoder 1015 (FIG. 1) is input into the 
video signal input terminal 1101" (Col. 16, line 51); "the image 
data unit of one pixel is 16 bits, for example, and this memory 
capacity is divided into two portions" (Col. 22, line 14); and 
"the head of the image data unit of the latter half VSj comes in 
contact with the tail of the image data unit of the former half 
Vsi, so that the processing image data having n(1600) pixels per 
line which is the same as the original input image data VS is 
obtained." (Col. 28, lines 25-27). 

As applicants 1 attorney presented to the Examiner during 
the telephone interview of June 4, 2 004, applicants do not see 
any relationship between the above-referenced sections and FIG. 
28 of Sokawa et al. and "receiving a header data packet that 
includes a field for a blank start pixel value, which is a 
numerical value that indicates a number of pixels to be blanked 
out." Applicants respectfully request a guidance from the 
Examiner as to why the cited sections of Sokawa et al . are 
relevant to receiving a header data packet that includes a field 
for a blank start pixel value, which is a numerical value that 
indicates a number of pixels to be blanked out . 

In responding to the amendment mailed January 20, 2004, the 
Office Action states " [t]his argument is not persuasive because 
Tateyama teaches the claimed limitation "a head data packet" 
(see fig. 28)." However, as discussed above, FIG. 28 of 
Tateyama is merely a table. Applicants do not see any 
indication in Tateyama that any of the quantities in the table 
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of FIG. 28 is for inclusion in a header data packet that 
includes a field for a blank start pixel value, which is a 
numerical value that indicates a number of pixels to be blanked 
out 

In addition, the Office Action states " Sakawa teaches 
Referring to fig. 7 and fig. 22 input section 2040 receiving is 
configured to be able to receive up to two sets of 16 bit 
digital video signals . . . The head of the image data unit is 
the later half VSj (col. 28, lines 25-26). Once the first input 
buffer portion is filled with the input image data, the write 
pointer Pw points to the head address of the second (right) 
input buffer portion which is vacant (col. 22, lines 23-25). 
That means blanking out one or more pixels start at the address 
(0) of the address where the read pointer P R points (see fig. 
12C) . A read pointer P R points to the head address of the first 
input buffer portion, starting the read of the input image data 
from the first input buffer portion (fig. 12B, col. 22, lines 
27-31)." Applicants still do not see in the above referenced 
section any teaching or suggestion of "receiving a header data 
packet that includes a field for a blank start pixel value, 
which is a numerical value that indicates a number of pixels to 
be blanked out." A guidance from the Examiner is requested. 

The Office Action further states " [t]hese arguments are not 
persuasive because packet header defines in Microsoft Computer 
Dictionary, fourth edition, the portion of a data packet that 
precedes the body (data) . The header contain data such as source 
and destination addresses, and control and timing information, 
that is needed for successful transmission. Therefore, the 
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combined teaching of Tateyama and Sokawa meet the claimed 
limitation "the header data packet"." 

Applicants submit that "the header data packet" in the 
present application is not identical to "a header of a packet" 
which is used for data communications, and typically include 
source and destination addresses. By way of example, as the 
applicants* attorney presented to the Examiner during the 
telephone interview of June 4, 2004, a header data packet is 
described, for example, on pages 37, line 14 through page 40, 
line 12 of the specification as filed in the present 
application . 

In particular, Table 2 on page 37 and Table 3 on page 39 
show the fields of the header data packet, including the "Blank 
Pixel Count" field, which can be used to store a blank start 
pixel value, which is a numerical value that indicates a number 
of pixels to be blanked out. Of course, the claims of the 
present application would cover receiving a header data packet 
having a format different from Tables 2 and 3 as long as they 
include a field for a blank start pixel value, which is a 
numerical value that indicates a number of pixels to be blanked 
out, or any equivalents thereof. 

In view of the above, applicants submit that Tateyama, 
Sokawa et al . and Microsoft Computer Dictionary, fourth edition, 
individually or together in any combination, do not teach or 
suggest " [a] method of horizontally scrolling a display window 
to the left comprising the steps of: receiving a header data 
packet that includes a field for a blank start pixel value, 
which is a numerical value that indicates a number of pixels to 
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be blanked out" as recited in claim 1. Therefore, applicants 
request that the rejection of claim 1 be withdrawn and that it 
be allowed. 

Since claims 2-6, and 25 depend, directly or indirectly, 
from claim 1, they incorporate all the terms and limitations of 
claim 1 in addition to other limitations, which together further 
patentably distinguish them over the cited references. 
Therefore, applicants request that the rejection of claims 2-6 
and 25 be withdrawn and that they be allowed. 

In particular, claim 25 recites "receiving a header data 
packet comprises receiving a plurality of data packets including 
the header packet and a plurality of graphics data packets, each 
of the plurality of data packets comprising a second field 
indicating whether it is the header data packet or one of the 
plurality of graphics data packets , wherein the plurality of 
graphics data packets contain the graphics data." ( Emphasis 
Added ) . 

In rejecting claim 25, the Office Action does not address 
"a second field indicating whether it is the header data packet 
or one of the plurality of graphics data packets." The Office 
Action merely states "Sokawa teaches a header data packet 
comprising the RGB signal data (col. 16, line 51), the image 
data unit of one pixel is 16 bits (col. 22, line 14), the head 
of the image data unit VSj , and the tail of the image data unit 
of the former half Vsi (fig. 22, col. 28, lines 25-27)" which do 
not appear to applicants to show the claimed limitations of 
claim 25. 
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Claim 7 recites, in a relevant portion, "receiving a header 
data packet that includes a field for a blank start pixel value, 
which is a numerical value that indicates a number of pixels to 
be blanked out." Claims 13 and 21 each recite, in a relevant 
portion, "a window controller for transmitting a header data 
packet to the display engine, the header data packet including a 
field for a blank start pixel value, which is a numerical value 
that indicates a number of pixels to be blanked out." For 
reasons similar to those state above in reference to claim 1, 
applicants request that the rejection of claims 7, 13 and 21 be 
withdrawn and that they be allowed. 

Since claims 8-12, 14, 15, 19 and 22-24 depend, directly or 
indirectly, from claims 7, 13 and 21 respectively, they 
incorporate all the terms and limitations of claim 7, 13 or 21, 
in addition to other limitations, which together further 
patentably distinguish them over the cited references. 
Therefore, applicants request that the rejection of claims 8-12, 
14, 15, 19 and 22-24 be withdrawn and that they be allowed. 
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In view of the forgoing remarks, applicants respectfully 
request an early issuance of a patent with claims 1-15, 19 and 
21-25. If there are any remaining issues that can be addressed 
over the telephone, the Examiner is invited to call applicants' 
attorney at the number listed below. 



Respectfully submitted, 



CHRISTIE, PARKER & HALE, LLP 
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